-
Notifications
You must be signed in to change notification settings - Fork 236
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rendervulkan.cpp: Use less conservative (memory and execution) barriers #1108
Rendervulkan.cpp: Use less conservative (memory and execution) barriers #1108
Conversation
1bcff26
to
80d279d
Compare
80d279d
to
b1994b4
Compare
c69232d
to
c4c2be1
Compare
c4c2be1
to
a1d27df
Compare
…d of VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT for reshade runtime barrier
e99ef1e
to
fb98ddc
Compare
I really dislike the idea of encoding certain task types. We should probably make this more akin to a proper render graph. |
uhh yeah I guess... |
@Joshua-Ashton NEW UPDATE: EDIT |
Going to close this, since it is clear that a rendergraph-based syncronization approach is what's desired. |
This PR tries to optimize barrier usage w/ shaders by getting ahead-of-time information of the shader usage pattern in vulkan_composite()
I've tested this PR for syncronization hazards w/ the Vulkan Validation Layer's sync + queueSubmit() validation.
The only sync hazard it showed was a Present-After-Write around vkQueuePresentKHR that is also detected w/ ValveSoftware/gamescope/master (not sure if it is a false positive or is a real issue...).
I will note that I had to force.oldLayout
for shaders to beVK_IMAGE_LAYOUT_GENERAL
instead ofVK_IMAGE_LAYOUT_UNDEFINED
, because the validation layers would report sync hazards from what it detects is a layout transition from undefined -> general...EDIT: fixed the issue mentioned in the crossed out part